1. Field of the Invention
The present invention relates to application programming interfaces (APIs), and more particularly, to detect and to resolve APIs in a distributed system.
2. Description of the Prior Art
A distributed system is a network of electronic devices interconnecting with each other through the use of a network. The devices typically include computers ranging from personal laptops to large mainframes, but may also include other forms of computing devices such as mobile phones and home entertainment devices. A server device in the system provides services to other devices in the network by accepting request messages sent from a client device over the network, and performs actions according to the request message. For example, a network printer may print out a document upon receiving a printing request, a network camera may pan to the left upon receiving a panning request, and a database server may return a list of sales records upon receiving a sales report request. To trigger such actions on a server, a client device needs to know what actions are available on the server, as well as the messages needed to trigger the actions. More specifically, a client device needs to understand the application programming interfaces (APIs) of the server. With the knowledge of the server's APIs, the client device may trigger actions on the server by using corresponding methods described in the APIs.
If a client device intends to communicate with a particular server which is known when the client device is being developed, the knowledge of the server and its APIs can be built into the client device directly. For example, a client device may be built to obtain map information from a particular web-based map server to display restaurant locations on a map. Since the web-based map server is chosen at development time, the information such as the web server's access URL and its APIs can be compiled into the client device's program.
In many applications, however, the server's information is unavailable while a client device is being developed. For example, different company's networks may have different printer servers, network cameras, or database servers. The information about these servers is available only when a client device is participating in the network at runtime, but not at development time. Historically, to build a client device to communicate with such servers, the program in the client is built to work with a particular set of APIs, and the client uses an API detection mechanism to interrogate whether a given server supports the APIs at runtime. Since a client device may encounter many different servers in different networks, it is often preferred that the API detection mechanism can be applied to a wide range of servers. This is increasingly important with advances in the Internet and in mobility technologies, in that a client device has the potential to communicate with any server in the world.
Unfortunately, at present, API detection mechanisms can only be applied to a very limited set of servers that are closely related to the client device during their development phase, and may even produce faulty results when applying to other servers. This is because most API detection mechanisms require some server specific information in the client device. Such information is not available at runtime and therefore must be built into the client device beforehand.
For example, with the current API detection mechanism, a server may present its APIs to a client by giving the client a list of API names, such as CORBA interface IDs or Java interface class names. The client then compares the names with the API names that the client recognizes. However, the API definition that each name represents is available only at development time, and the API definition information is compiled into both the client's and the server's programs; such information is not obtainable through the detection mechanism at runtime. A foreign client device that does not have the same API definition information will not be able to know what the API names on the server represent. Worse yet, the foreign client device may have a different API definition that happens to be assigned with the same name used by the server, a situation commonly known as API naming collision. Consequently, the foreign client device will mistakenly assume that the server supports the API definition known by the foreign client, whereas the server actually supports a different API definition. That is, the client and the server do not have the consensus on the definition of the API identified by the name.
For another example, with the current API detection mechanism, a server may provide the full definition of its APIs to a client, such as a list of function names that can be called remotely. This method does not eliminate the need of having server specific information in the client device, in that the client must know the intended use of the functions on the particular server. A function named ‘draw’ on one server may produce graphic outputs, whereas a function named ‘draw’ on another server may end a chess game in a tie. Accordingly, knowing that the API definition obtained from a foreign server contains a function named ‘draw’ is not enough for a client device to perform graphic actions on a server, whereas blindly calling the function on the foreign server may lead to unintended results. This problem is also caused by the lack of consensus on the API definition due to API naming collision.
The aforementioned problems make current API detection mechanisms difficult to apply in detecting a web server's APIs. The large number of web application servers in the Internet dramatically increases the possibility of API naming collision, whereas reaching the consensus on API definitions among different web servers is difficult since each web server may be operated by a different party. Without the consensus on API definitions, a client cannot reliably detect a foreign web application server's API at runtime and correctly communicate with the server thereafter.
Therefore what is required is a mechanism that allows a client device to automatically resolve the APIs of a server in such way that the consensus of API definitions can be established between the client and the server even if the client, the server, and the API definitions are each developed by a different party.